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ABSTRACT 



The mission of the Branch Clinic, Bancroft Hall, is to 
meet the primary health care needs of the Brigade of 
Midshipmen, U. S. Naval Academy- Equally important, the 
Branch Clinic must monitor the physical qualifications of 
those midshipmen and make recommendations to Naval Academy 
authorities and higher echelon activities regarding their 
suitability to participate in ongoing professional 
development activities and for subsequent service as 
commissioned officers of the Navy and Marine Corps. 

This thesis proposes a mi crocomputer -based Physical 
Qualifications Monitoring System for the Branch Clinic. 
Developed as a prototype, the system would provide the 
clinic staff with their first significant hands-on 
experience with current information systems technology and 
serve as a basis for a more fully developed mi crocomputer- 
based system or as a preliminary requirements specification 
for a mainframe-based system. 
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I 



INTRODUCTION 



The mission o-f the Branch Clinic, Bancroft Hall, is to 
meet the primary health care needs o-f the Brigade o-f 
Midshipmen, U. S. Naval Academy. Equally important, the 
Branch Clinic must monitor the physical qualifications of 
those midshipmen and make recommendat i ons regarding their 
suitability to participate in professional development 
activities and for subsequent service as commissioned 
officers of the Navy and Marine Corps. These 
recommendations are provided to both Naval Academy 
authorities and higher echelon acitivies (e.g., Naval 
Aerospace Medical Institute, Naval Medical Command, Naval 
Military Personnel Command , Commandant of the Marine Corps) . 

To date, the Branch Clinic has monitored physical 
qualifications without data processing support. This thesis 
proposes a mi crocomputer-based Physical Qualification 
Monitoring System (ROMS) to augment existing manual 
procedures. The system is designed to help the Branch 
Clinic answer inquiries on the physical status of midshipmen 
and in preparing precommissioning physical examinations. 
Developed as a prototype, this system would provide the 
clinic staff with their first significant experience with 
current information systems technology. The proposed PQMS 
could, in turn, serve as the basis for a more fully 
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developed mi crocomputer — based system or as a preliminary 
requirements specification for a mainframe-based system. 

The thesis first describes the organizational context 
and overviews the problem. These sections are based 
primarily on personal experience as Administrative Officer, 
Branch Clinic, Bancroft Hall, during the period January 1982 
through July 1984, supplemented by telephone conversat i ons 
with the current staff and a site visit during December 
1985. Next, general characteristics of the PQMS proposal 
are examined, including design objectives methodology. The 
system outputs are then discussed, followed by the data 
structures and processing modules. The summary presents the 
proposed hardware/sof tware configuration of the system, 
highlights what PQMS is and is not, and offers some possible 
extensions to underlying concepts. 

The reader will find that this thesis is more pragmatic 
than theoretic. The information systems concepts are well- 
established in the literature; no new theory or technology 
is required or advocated. Rather these concepts are simply 
brought to bear on a real-life problem which has thus far 
gone unaddressed. Where appropriate, theory is discussed, 
but only to a level consistent with the needs of the reader. 
Every effort is made to focus on the problem, without 
obscuring key issues with unwarranted detail. 
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II. 



ORGANIZATIONAL CONTEXT 



A. MISSION AND ORGANIZATION OF THE U. S. NAVAL ACADEMY 

The mission of the U. S. Naval Academy (USNA) is to 
prepare midshipmen for service as commissioned officers of 
the Navy and Marine Corps. To accomplish this, particular 
emphasis is placed on the development of a midshipman as a 
whole — academically, professionally, morally, and 
physically CRef. l:p. 221. The organization of the Naval 
Academy reflects this proven approach. 

The Superintendent has overall responsibility for the 
Naval Academy and its large support complex. His principle 
assistants for the general admi ni strati on of the Annapolis 
Area complex are his immediate personal staff, the Deputy 
for Operations, and the Deputy for Management. Regarding 
matters specific to the Brigade, the Dean of Admissions, 
Academic Dean, and Commandant of Midshipmen assist the 
Superintendent in the recruitment and subsequent academic 
and professional development of midshipmen. 

Of these, the Commandant of Midshipmen is most directly 
involved with the day-to-day functioning of the Brigade and 
responsible for the uniquely military aspects of midshipmen 
development — professional, moral, and physical CRef. l:p. 
241. Several departments under the Commandant assist him 
with this task. The Division of Professional Development 
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(PRODEV) conducts ongoing training in pro-f essional areas, 
such as leadership, military law, seamanship, and 
navigation. This division also coordinates the summer 
cruise program, providing midshipmen with operational 
experience with fleet and shore-based units of the Navy and 
Marine Corps, and the service selection process by which 
individuals choose the warfare specialty in which they will 
serve subsequent to graduation. The Brigade Officers and 
Brigade Chaplains share responsibility for the moral 
development of midshipmen through a blend of religious 
activities, leadership, guidance, and personal example. The 
physical development of the Brigade is primarily handled by 
the Physical Education Department, which provides formal 
physical education courses and coordinates an extensive 
intercollegiate and intramural sports program. 

The organization of the Brigade of Midshipmen itself 
also contributes to accompl i shment of the Naval Academy 
mission. The Brigade is divided into six battalions, each 
headed by a senior officer (rank of 0-5 or 0-6) of the Navy 
or Marine Corps. A battalion, in turn, consists of six 
companies, each under command of a Company Officer from the 
Navy or Marine Corps (rank of 0-3 or 0—4). The company is 
the basic organizational unit of the Brigade and consists of 
approximately 125 midshipmen. Midshipmen from all four 
classes (or year group levels) are assigned to each company. 
CRef. 1: p.241 



1 1 



B. MISSION AND ORGANIZATION OF THE NAVAL MEDICAL CLINIC AND 

BRANCH CLINIC, BANCROFT HALL 

The Naval Medical Clinic (NMCL) , Annapolis, is a tenant 
command of the U. S. Naval Academy, responsible for 
providing general /speci al ized outpatient clinic services 
primarily for active duty Navy and Marine Corps personnel, 
midshipmen, and active duty members of other Federal 
Uniformed Services. NMCL Annapolis also provides outpatient 
care to other eligible beneficiaries of the Annapolis Area 
complex <e.g., dependents of active duty personnel , retirees 
and their dependents, etc.) on a space-available basis. 

This activity is organized under a Commanding Officer who 
reports directly to the Commander, Naval Medical Command, 
National Capital Region, Bethesda, Maryland, and to the 
Superintendent, U3NA, for additional duty and area 
coordination. CRef. 21 

NMCL Annapolis is physically and functionally divided 
into two distinct units, the Main Clinic and Branch Clinic, 
Bancroft Hall. The Main Clinic is off the main USNA campus 
in the buildings which formerly comprised the Naval Hospital, 
Annapolis. In general, this unit consists of the Office of 
the Commanding Officer, all administrative support elements 
of the command, ancillary support services <i.e. , Laboratory 
Pharmacy, and Radiology), and those clinical services 
provided primarily for non— active duty benef i ci ar i es , such 
as Primary Care, Pediatrics, and Occupational Health. 
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The Branch Clinic is on the main campus of the Naval 
Academy in the basement o-F Bancro-ft Hall, the dormitory 
facility for the Brigade of Midshipmen. This clinic is 
organized under the Senior Medical Officer and consists of 
several small, but distinct work centers, including Military 
Sick Call, Physical Examinations, Treatment Room, 

Observation Ward, Orthopedics/Sports Medicine, Physical 
Therapy, Optometry, and satellites of the ancillary support 
services at the Main Clinic. The primary beneficiaries of 
the Branch Clinic are the Brigade and the active duty staff 
of the Naval Academy. 

C. NAVAL ACADEMY/BRANCH CLINIC RELATIONSHIP 

The Senior Medical Officer reports directly to the 
Commanding Officer, NMCL Annapolis. Due to the close 
relationship between the Naval Academy and Branch Clinic, 
however, the Senior Medical Officer also has additional duty 
orders to the Superintendent. This relationship has three 
dimensions which parallel the "life cycle" of a midshipman. 

First, the Senior Medical Officer is a member of the 
USNA Admissions Board. Each year this board, chaired by the 
Superintendent, reviews the qualifications of the 14, 000+ 
applicants for admission to the Naval Academy to arrive at a 
plebe (freshman) class of approximately 1300. The Senior 
Medical Officer's role on this board is to establish the 
medical qual i f i cati ons of the applicants. The principle 
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vehicle for that determination is the candidate medical 
examination, conducted under the auspices o-f the Department 
of Defense Medical Examination Review Board (DODMERB). An 
interservice agency, DODMERB is responsible for scheduling 
the medical examinations for candidates to all service 
academies and ROTC programs and for making preliminary 
determinations on the medical status of the candidates. 
DODMERB forwards their findings for use by the USNA 
Admissions Board- The Senior Medical Officer advises the 
Board regarding medical standards and the implications of 
waivering those standards on an individual's tenure as a 
midshipman and on possible limitations to career prospects 
and duty assignments. 

Second, the Branch Clinic is responsible for maintaining 
the good health of the Brigade of Midshipmen- This is done 
through routine sick call, specialty clinics, immunizations, 
screening tests and examinations, and health education 
programs- When the level of care needed by a midshipman is 
beyond their capabilities, the clinic staff coordinates that 
care with nearby military treatment facilities and, if 
warranted, with civilian facilities. 

Finally, the Branch Clinic monitors the physical 
qualifications of the 4500+ members of the Brigade- This 
task has both short and long term consi derat i ons- On the 
short term, the Senior Medical Officer must ensure that 
individuals are medically qualified to perform their duties 
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on a day-to-day basis and to participate in their physically 
demanding professional development activities. From a 
long-term perspective, he must also make recommendat i ons to 
higher authority regarding their suitability to serve as 
commissioned officers of the Navy and Marine Corps -following 
graduation. 

It is important to note that although the Senior Medical 
O-f-ficer reports to the Superintendent -For additional duty, 
he is more directly in-Fluenced by and responsible to the 
Commandant o-f Midshipmen -for several reasons. Not only is 
the Commandant invariably a -flag of-Ficer or flag-selectee, 
but he is also a line officer, whereas the Senior Medical 
Officer is junior (speci f i cal 1 y , a Captain) and from a staff 
corps. Both the primary beneficiaries and the building 
containing the Branch Clinic are under control of the 
Commandant. Furthermore, those Naval Academy authorities 
most involved with the daily activities and future careers 
of the Brigade, the Brigade Officers and Division of 
Professional Development, also work for the Commandant. 
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Ill 



PROBLEM STATEMENT/PROPOSED SOLUTION APPROACH 



A. PROBLEM OVERVIEW 

Throughout an individual's -four years as a midshipman, 
much pertinent in-formation is documented in the Health 
Record regarding physical qual i f i cat i ons. Sources include 
the candidate physical examination for admission into the 
Naval Academy; documentation of routine health care; 
hospi tal ization and surgery reports; Medical Boards; and 
special purpose screenings, tests, and examinations. 

However, this information has never been fully integrated to 
provide readily accessible physical qualification profiles 
on the Brigade. The only means of obtaining even a 
preliminary indication of a midshipman's physical 
qualification status is to review that individual's Health 
Record vis-a-vis the physical standards established by 
higher authority. This is a time-consuming process which 
currently must be repeated for each separate inquiry and 
requires detailed knowledge of physical standards by the 
reviewer. When requests are received for information 
involving large segments of the Brigade (e.g., Which 
midshipmen in a given year group are physically qualified 
for duty as Naval Aviators or Naval Flight Off icers?) , the 
Branch Clinic must manually review all pertinent Health 
Records to respond, often to the exclusion of other work. 
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Due to the Health Record layout, this review process can 
lead to important data being overlooked, especially when the 
reviewers are inexperienced. This is of particular concern 
since the Branch Clinic must augment its sta-f-f with health 
care providers from other naval medical facilities and Naval 
Reserve units to complete the annual precommissioning 
physical examination evolution. Although these providers 
are competent in their own right, they are often unfamiliar 
with current standards and the exacting requirements of 
these physical examinations and are apt to overlook critical 
data in the Health Record. 

B. PROPOSAL 

Given the volume of queries and physical examinations 
handled by the Branch Clinic each year, the need exists for 
current, easily retrievable physical qual if ication profiles 
on all midshipmen. This thesis proposes a mi crocomputer- 
based Physical Qualification Monitoring System (PQMS) to 
meet that need. With such a capability, the Branch Clinic 
would be more responsive to inquiries from Naval Academy 
authorities regarding the physical qualifications of 
midshipmen. Additionally, the accuracy of precommi ssi oni ng 
physical examinations generated by the Branch Clinic would 
be enhanced, so that midshipmen are recommended for only 
those warfare specialties they are physically qualified for. 
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C. SECONDARY DESIGN OBJECTIVES 



Several secondary objectives motivated the design of the 
prototype Physical Qualifications Monitoring System. The 
most important of these are presented below in their 
approximate order of importance: 

1. Minimize the risk exposure of the Branch Clinic. 

At least three factors affect the degree of risk in 
any information systems project CRef. 3:pp. 313—3143: 

- Project size (the larger the project, the greater the 
risk) , 

- Experience with the technology to be employed (the 
greater the prior experience, the lesser the risk — and 
vice versa) , and 

- Project structure (the more well-defined and fixed the 
system outputs, the lesser the risk). 

Clearly, all risk cannot be avoided. This is especially 

true in this instance with regard to experience with the 

technol ogy . 

Nolan has identified four phases of organizational 
learning relevant to information systems technology. These 
range from identifying a technology of potential value to an 
organization and undertaking a pilot project (Phase 1) to 
widespread technology diffusion where experience in one 
branch of an organization is easily transferred to other 
branches (Phase IV). CRef. 3:p. 303 The only known 
automated data processing experience of the Branch Clinic is 
the use of punched cards for immunization evolutions and the 
casual use by a limited number of staff of the Brigade 
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Roster System on the Naval Academy Time-Sharing System to 
generate rosters of midshipmen. 

According to Nolan's scheme, then, the clinic is clearly 
at the beginning o-f Phase I, where the risks to an 
organization are inherently higher. To counteract this, 
emphasis -focused on the other two risk -factors. The outputs 
o-f the system were identified early and fixed in both form 
and content. By keeping these outputs to the minimum needed 
to evaluate the PQMS prototype and meet the reporting needs 
of the Branch Clinic, the project was also kept to a 
manageable size. 

2. Minimize the time investment to learn and to use the 

prototype. 

Key to the acceptance of any system is that the 
users be able to learn and use the system quickly. To 
achieve this, the PQMS Users' Manual is less than 40 pages 
long and provides step-by-step instructions for all 
processing modules, including very detailed explanation of 
those off-line procedures involving the Naval Academy 
Time-Sharing System. The system is itself menu— driven so 
that the user need not understand the underlying programs 
and programming language. Personal data (e.g., name. Social 
Security number, date of birth, etc.) is downloaded from 
existing Naval Academy files so that this data does not have 
to be rekeyed or maintained by the Branch Clinic staff. 
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3- Provide mechanisms -for data security. 

Although PQMS is a prototype, the system stores 
personal data covered by the Privacy Act of 1974 and 
sensitive medical information. Security against 
unauthorized access, therefore, is a prime concern, so 
appropriate safeguards are part of the design. Users must 
enter a password to log onto the system, and the password 
can be easily changed once successfully logged on. Privacy 
Act Warning statements are displayed on entering and exiting 
the program. Two types of reports are provided, detailed 
reports for use within the Branch Clinic and summary reports 
for distribution outside the clinic. 

4. Provide a repository for current physical standards 
i nformation . 

Continuity is a problem at any military activity due 
to the frequent rotation of personnel. The Branch Clinic is 
no exception, with a new Senior Medical Officer and Head, 
Physical Examinations Department, reporting aboard every few 
years. Therefore, the PQMS was designed to store detailed 
physical standards information which would be preserved 
despite staff changes. 

D. DESIGN METHODOLOGY 

To facilitate development of the PQMS, considerable 
thought was devoted to which of two common design 
methodologies to use: i) data f low— or i ented , ii) data 

structure-or i ented . The former, data flow-oriented design. 
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considers information as a continuous "flow" from input 
through a series of transforms (processes) to output. This 
data flow is mapped to provide a representation of software 
structure. CRef. 4:pp. 178-1793 

Although data flow-oriented design can be used for a 
broad range of applications and is probably more widely 
documented in the literature, a data structure-or iented 
design approach was chosen for ROMS. This was primarily due 
to the well-defined structure of the inputs, data base 
files, and outputs of the system. Data structure-oriented 
design proposes that where such well-defined structures 
exist, they can be used as the basis for software 
development. Rather than considering data flows and data 
flow diagrams, this approach transforms representations of 
data structure into representati ons of software structure. 
The procedural aspects of processing modules are essentially 
a by-product of data structure. CRef. 4:pp. 205-2073 
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IV. PQMS OUTPUTS 



The intent of the Physical Qualifications Monitoring 
System is to provide current , easily retrievable physical 
qualification profiles on all Naval Academy midshipmen. The 
form and content of these profiles, in turn, are based on 
the information needs of both the direct users (the Branch 
Clinic staff) and indirect users (all others to whom 
information from the system is provided). 

PQMS provides information at two levels of detail. To 
answer inquiries on specific midshipmen and to facilitate 
the annual precommissioning physical examination evolution, 
detailed reports are needed. These show not only an 
individual's physical qual if icati on status by warfare 
specialty, but also the disqualifying conditions, standards, 
and waivers which underlie those determinations. To answer 
inquiries from outside the clinic on organizational segments 
of the Brigade, such as a company or year group, summary 
reports which show physical qualification status by warfare 
specialty are adequate. The next two sections discuss the 
specific format and content of these detailed and summary 
reports. 

A. DETAILED REPORTS 

Figure 1 shows the general format of the detailed 
reports produced by PQMS. 



22 



+ 



! Name: MCGIFFIN PHILO Alpha: 891234 Coll: 09 I 

! SSN: 123456789 Sex: M DOB: 620727 ! 

: i 

! Code Disqualify Date AIR NFO OPS WAR SUB NUC URL NC RL I 

I ! 

! XXXXX XXXXXXXXXXXXXXXXXXXXXXXXX XX/XX/XX XX XX XX XX XX XX XX XX XX ! 

I • ■ I 

I • • ■••••••■•• I 

I ■ • I 

! I 

! Summary: XX XX XX XX XX XX XX XX XX ! 

I I 

l i 

! Comments: ! 

l i 

l > 

: XX/XX/XX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX I 

I I 

la • I 

I I 

I ■ a I 

I • 

la a I 

I > 

I l 

I i 

I I 

4 f 

Figure 1. Detailed Physical Qualification Status Report 

The heading data on this report is self-explanatory, except 
for "Alpha:." The alpha number is a numeric identifier 
assigned to each midshipman on entry into the Naval Academy 
and is the key for most records maintained by the Naval 
Academy. It is formed by concatenati ng the last two digits 
of midshipman's year group with a four-digit number 
representing the alphabetized position of that person's name 
within the Brigade. 

The next section of the report is a detailed and 
summarized listing of physical qualification status 
information. For each disqualifying condition recorded for 
a midshipman, a text description and date stamp (reflecting 



how current that entry is) is shown. In addition, a set of 
"flags" reflects the impact of that disqualifier on the 
midshipman's eligibility for the various warfare 
specialties. The column headers for these flags represent 
the following specialty groups: 



AIR 


— Naval Aviator 


NlIC 


- Sur-face Nuclear 


NFO 


- Naval Flight Officer 


URL 


- Unrestricted Line 


OPS 


- Special Operations 


MC 


— Marine Corps 


WAR 


- Special Warfare 


RL 


- Restricted Line/ 



Staff Corps 



SUB - Submarine Duty 

The flags themselves can assume one of the following values: 

PQ - physically qualified 

WG — not physically qualified/waiver granted by higher 
authority 

LW - not physically qualified/limited waiver granted by 
higher authority 

WR - not physically qualified/waiver requested from higher 
author i ty 

UE - undergoing evaluation/status indeterminate at this 
time 

NQ - not qualified 

The summary flags show the overall impact of the individual 
flags on a midshipman's physical qual i f i cat i on status for 
each warfare specialty. 

The final section of the detailed report displays 
f ree-te>;t comments. These are limited to 60 characters 
each, date stamped, and provide information specific to a 
midshipman which the PQMS cannot otherwise store. 
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The detailed report format is generic and can be 
generated three different ways. First, a single report can 
be displayed on the CRT screen of the microcomputer . 

Because of the 80 x 25 character size limitation of a CRT, 
the report is split into two screens, one containing the 
header and disqualifier information and the other containing 
any comments. Second, the user can direct the output to an 
attached printer, producing a single— sheet report. Finally, 
a series of detailed reports on all midshipmen in a given 
company and year group can be directed to the printer. This 
option is primarily intended to facilitate the annual 
precommissioning physical examination process by providing 
reports in the same logical unit that the examinations are 
processed. 

B . SUMMARY REPORTS 

Figure 2 shows the general format of the summary reports 
produced by PQMS. 

Given the discussion of the prior section, the contents 
of this report need no additional explanation. The report 
simply shows physical qualification summaries for whichever 
of two categories of midshipmen is chosen, either a year 
group sorted by company or a company sorted by year group. 

In both cases, each distinct subgroup (company or year 
group, respectively) is listed on a separate sheet of paper. 
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BRANCH CLINIC, BANCROFT HALL 
AWAPOLIS, MD 21402 

PHYSICAL QUALIFICATIONS STATUS REPORT 

ALPHA NAME DATE AIR NFO OPS WAR SUB NUC URL MC RL 

« COMPANY M (or YEAR GROUP #«) 

XXXXXX XXXXXXXXXXXXXXXXXXXXXXXX XX/XX/XX XX XX XX XX XX XX XX XX XX 



4 -+ 

Figure 2- Summary Physical Quali-fi cation Status Report 

C. DISQUALIFICATION CODES REPORT 

The PQMS can also produce printouts o-f its data base of 
physical standards in the format shown in Figure 3- The 
code listed in this report is a f ive-character , alphanumeric 
identifier which uniquely identifies each standard in the 
data base- The text description, date stamp, and flag 
fields are analogous to those of the detailed physical 
qualification status report with one exception- The flags 
can only assume values of PQ or NQ. The standards data 
file is discussed in greater detail in the next chapter. 

PQMS can sort and print these listings either by code or 
alphabetically- The report is designed for use as a 
reference guide when recording di squal i f i er s for midshipmen, 
eliminating the need to commit the codes and text 
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BRANCH CLINIC, BANCROFT HALL 
ANNAPOLIS, MD 21402 

DISQUALIFICATION CODES 

CODE DISQUALIFY DATE AIR NFO OPS WAR SUB NUC URL 1C RL 

XXXXX XXXXXXXXXXXXXXXXXXXXXXXXX XX/XX/XX XX XX XX XX XX XX XX XX XX 



Figure 3. Disqualification Codes Report 

descriptions to memory. In addition, the listings can be 
distributed outside the Branch Clinic, either as a reference 
guide for the indirect PQMS users or for validation of the 
standards data by higher authority (e.g.. Naval Aerospace 
Medical Institute or Naval Medical Command). 
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V 



DATA STRUCTURES 



The data structures of the Physical Qual if ications 
Monitoring System provide the basis for the outputs and 
processing modules of the system. These structures are 
based on the relational data base model and implemented 
using the popular microcomputer product, dBASE III. This 
chapter provides a brief overview of this model and then a 
detailed discussion of the five PQMS data base files: 
BRIGADE, STANDARDS, DISQUALIFIERS, COMMENTS, and SUMMARY. 

A. OVERVIEW OF RELATIONAL DATA BASE MODEL 

The relational model uses two-dimensional tables to 
represent data. These tables (or relations) have several 
important properties. Each entry in the table can contain 
only a single-value; repeating groups or arrays cannot be 
used as entries. Each column has a unique name and is 
called an attribute or field. All entries within a column 
are of the same type and come from the same domain of 
permissible values. The rows of the relation are the 
individual records of the data base file. No two rows in 
the table may be identical, and each row is identified by a 
unique key formed by some attribute or combination of 
attributes from the relation. The relational model not only 
requires each record to have a primary key, but also permits 
alternate keys if they too are unique. 

28 



CRef. 5:pp. 243-2451 



As is the case with the PQMS, a data base usually 
consists of several different relations or tables. Key 
questions are then: What kinds of relationships can exist 

among the tables and how are they represented? There are 
three basic types of relationships. A tree, also known as a 
hierarchy, consists of a collection of records and 
one-to-many relationships among records. Each record can 
have one and only one parent. A simple network relaxes this 
definition slightly, so that a record can have more than one 
parent so long as they are of different types. Lastly, a 
complex network consists of a collection of records and 
many— to— many relationships (i.e. , records may have multiple 
parents including some which are of the same type). [Ref. 
5:p. 117—1221 As illustrated later in this chapter, PQMS 

uses both the tree (between the BRIGADE and COMMENTS data 
base files) and complex network (between the BRIGADE and 
STANDARDS data base files). 

Just as different types of relationships may exist among 
relations, so too can the relationships be represented in 
various ways. The relational model is noteworthy in that 
the table entries themselves identify any relationships, 
rather than requiring them to be explicitly defined when the 
logical format of the data base is first specified. The 
table entries typically used for this purpose are the record 
keys (or portions of them), although this is not always 
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true. Relationships among the PQMS data base tiles are 
detined exclusively by record keys. 

B. BRIGADE DATA BASE FILE 

The BRIGADE data base tile contains personal, 
non-medical data on each midshipman. Figure 4 describes 
this tile. The data elements are a subset ot those 
contained in the Brigade Roster File (BROSTER) , a well- 
established data base maintained by the Midshipman Personne 
Oftice. The procedural aspects ot downloading this data to 
the PQMS microcomputer are given in the next chapter. 

Two keys are used tor BRIGADE, Alpha and SSN. Both are 
unique and allow the user more tlexibility in querying PQMS 
In addition, the tile is indexed (i.e., sorted) on three 
different fields, Alpha, SSN, and the concatenation of 
Company+Al pha , to accelerate search routines and overall 
program execution, as well as to properly sequence printed 
outputs. 

C. STANDARDS DATA BASE FILE 

Figure 5 describes the STANDARDS data base file. In 
essence, this file is the Branch Clinic's corporate memory 
of the physical standards contained in the Manual of the 
Medical Department and other pertinent directives. Each 
record in STANDARDS includes a unique code established by 
the Branch Clinic, a text description of the disqualifying 
condition, and a series of nine flags which reflect the 
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Data Base File: BRIGADE 

Description: Personal, non-medical data on each midshipman 

Data Elements: 



Field Name 


Type 


Length 


Remarks: 


Alpha 


Char 


& 


The first two digits of the alpha number 
are the last two digits of the year 
in which the midshipman will graduate. 
The regaining four digits are reflect 
the alphabetized position of the 
midshipman's name within the Brigade, 
without regard to year of graduation. 

EXAMPLE: 391234 


SSN 


Char 


9 


Social Security Number of midshipman, 
non-hyphenated. 

EXAMPLE: 123456789 


Last 


Char 


20 


Last name of midshipman, in all capital 
letters and padded with blanks to the 
right as necessary. 

EXAMPLE: MCGIFFIN 


First 


Char 


15 


First name of midshipman, in all capital 
letters and padded with blanks to the 
right as necessary. 

EXAMPLE: PHILO 


Sex 


Char 


1 


Sex of midshipman, M (male) or F (female). 
EXAMPLE: M 


DOB 


Char 


6 


Midshipman's date of birth, YYMMDD format. 
EXAMPLE: 620727 


Company 


Char 


2 


Company to which midshipman is assigned, 



! expressed as two digits (01,. ..,36). ! 

! EXAMPLE: 09 ! 

! Primary Key: Alpha ! 

1 Alternate Key: SSN ! 

! Indexes: Alpha, SSN, Company +Alpha ! 

+ i- 



Figure 4 



Description of BRIGADE Data Base File 



Data Base File: STANDARDS 

Description: Physical standards fro® the Manual of the Medical Department and 

other pertinent directives 

Data Elements: 



Field Name Type Length 
Code Char 5 



Text Char 



AIR_std Char 



NFO.std 


Char 


2 


OPS.std 


Char 


n 

L. 


WAR.std 


Char 


2 


SUB’std 


Char 


0 


NUC_std 


Char 


2 


URL'std 


Char 


2 


MC_std 


Char 


n 

L 


RL_std 


Char 


0 

L. 


Date 


Date 


8 



Primary Key: Code 
Indexes: Code, Text 



Remarks : 

Alphanumeric code based on International 
Classification of Diseases, 9th Edition, 
Clinical Modification, which uniquely 
identifies the disqualifying condition. 

EXAMPLE: 36850 

Text description of the disqualifying 
condition, using generally accepted 
medical terminology and abbreviations 
as needed to restrict the description 
to 25 characters or less. 

EXAMPLE: COLOR VISION DEFICIENCY 

Flag which indicates whether the disqual- 
ifying condition would render a 
midshipman physically qualified (PQ) 
or not physically qualified (NQ) for 
duty as a student naval aviator. 

EXAMPLE: NQ 

* SAA, except student naval flight officer. 

SAA, except special operations duty. 

SAA, except special warfare duty. 

SAA, except submarine duty. 

SAA, except surface nuclear duty. 

SAA, except unrestricted line. 

SAA, except U. S. Marine Corps. 

SAA, except restricted line/staff corps. 

Date of most recent update to standard, 
MM/DD/YY format. 

EXAMPLE: 03/27/96 

* SAA - Same as above 



Figure 
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Description of STANDARDS Data Base File 



impact o-f that condition on a midshipman's physical 
qualification for the various warfare specialties. The 
record also carries a date stamp showing when the entry was 
most recently updated. The key for STANDARDS is the Code 
field, and the file is indexed on both the Code and Text 
f i el ds. 

Some attributes of the STANDARD data base file warrant 
further elaboration. The Code field has been designed to 
accommodate the coding scheme of the Internat i onal 
Classification of Diseases, 9th Revision, Clinical 
Modification (ICD-9-CM). Basically, ICD-9-CM categorizes 
diseases and injuries and assigns a five-digit code to each. 
The first three digits identify the system of the body 
affected; the last two digits add the necessary detail to 
identify the specific disease or injury. Figure 6 > shows the 
major classifications of ICD-9-CM and their three-digit 
rubrics. CRef. 61 

The ICD-9-CM coding scheme was chosen for two reasons. 
First, ICD-9-CM is used throughout the Navy to classify 
morbidity and mortality information for statistical reports 
and to index medical treatment records by disease or injury. 
Therefore, the coding scheme is a familiar one and 
eliminates the need to develop a scheme unique to PQMS. 
Second, DODMERB is currently developing a new dictionary of 
disqualification codes based on ICD-9-CM, which the Branch 
Clinic could adapt to meet their own needs. This would both 
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Code Series Classification 



00100 - 13999 


Infectious and Parasitic Diseases 


14000 - 23999 


Neoplasms 


24000 - 27999 


Endocrine, Nutritional, and Metabolic Diseases 
and Immunity Disorders 


28000 - 28999 


Diseases of the Blood and Blood-Forming Organs 


29000 - 31999 


Mental Disorders 


32000 - 38999 


Diseases of the Nervous System and Sense Organs 


39000 - 45999 


Diseases of the Circulatory Systei 


46000 - 51999 


Diseases of the Respiratory System 


52000 - 57999 


Diseases of the Digestive System 


58000 - 62999 


Diseases of the Genitourinary System 


63000 - 67699 


Complications of Pregnancy, Childbirth, and the 
Puerperium 


68000 - 70999 


Diseases of the Skin and Subcutaneous Tissue 


71000 - 73999 


Diseases of the Musculoskeletal System and 
Connective Tissue 


74000 - 75999 


Congenital Anomalies 


76000 - 77999 


Certain Conditions Originating in the Perinatal 
Period 


78000 - 79999 


Symptoms, Signs, and Ill-Defined Conditions 


B0000 - 99999 


Injury and Poisoning 


SOURCE: International 


Classification of Diseases, 9th Edition, 



Clinical Modification, Commission on Professional and 
Hospital Activities, Ann Arbor, Michigan, March 1980. 



Figure 6. Classi f ication of Diseases and Injuries 



enhance consistency among these related systems and 
facilitate the recording of medical problems identified by 
DODMERB on the candidate medical examination into the PQMS 
data base. 

The domain of the flag fields in the STANDARDS data base 
file consists of only two possible values: PQ (physically 
qualified) or NQ (not physically qualified). At first, this 
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may seem unduly restrictive, since it implies that standards 
are absolute and disregard individual circumstances. 
Actually, these values are merely endpoints on a continuum 
and provide a first-cut determination of an individual 's 
physical qualification status. As discussed in the next 
section, these flags can be modified by those of the 
DISQUALIFIERS data base file to reflect specific situations, 
such as not physically qual i f i ed/wai ver granted, not 
physically qual i f i ed/wai ver requested, etc. 

D. DISQUALIFIERS DATA BASE FILE 

A complex relationship exists between the BRIGADE and 
STANDARDS data base files. This means that each midshipman 
record can be related to many standards (i.e. , a midshipman 
can have more than one disqualifying condition) and each 
standard can be related to many midshipmen (i.e., more than 
one midshipman can have a certain disqualifying condition). 
This many-to-many relationship can be illustrated as: 

-t h +• + 

! BRIGADE !« »i STANDARDS ! 

+ + + + 

Note the two-headed arrows pointing in both directions, 
indicative of a complex relationship. 

Complex relationships are awkward to implement, so the 
relational model decomposes such relationships using an 
intersection record. As the name implies, this record 
represents the merger, or “intersection," of two other 
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records CRef. 5:p. 1453. PQMS uses the DISGMJALIFIERS data 

base -file -for this purpose. 

The resulting simple network can be represented as: 



+ + 


+ 


“ + 


+ + 


! BRIGADE ! < — 


>>! DISQUALIFIERS 

+ 


!<<- 

- 4 * 


> ! STANDARDS ! 

+ + 



Note that the two resulting relationships are one— to-many, 
denoted by si ngl e— headed arrows pointing toward BRIGADE and 
STANDARDS. This means that each record in D I SQUAL I F I ERS can 
have only one parent in BRIGADE and one in STANDARDS. 

Figure 7 describes the DISQUALIFIERS data base -file. 

This -file contains a unique record tor each instance where a 
midshipman is identified to have a disqualifying condition. 
The key for these intersection records is the combination of 
the midshipman's alpha number and code assigned to the 
disqualifying condition (i.e., Alpha+Code) . Each record 
also has a series of flags correspondi ng to the nine warfare 
specialty categories. These are the flags which relax the 
rigid PQ/NQ flags of the STANDARDS file. For each warfare 
specialty, the flags from STANDARDS and DISQUALIFIERS are 
compared. If the STANDARDS flag is PQ, the condition is not 
disqualifying for that particular warfare specialty, so the 
DISQUALIFIERS flag is irrelevant and the resulting status 
flag is PQ. However, if the STANDARDS flag is NQ, it could 
be modified by any DISQUALIFIERS flag. If the corresponding 
DISQUALIFIERS flag is WG, LW, or WR the resulting status 
flag would also be WG, LW, or WR, respectively. If the 
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Data Base File: DISQUALIFIED 

Description: Intersection tile which decomposes the complex relationship 

between BRIGADE and STANDARDS into a simple network. 



Data Elements: 



Field Name 


Type 


Length 


Alpha 


Char 


6 


Code 


Char 


5 


AIR waiver 


Char 


2 



NFQ_waiver 


Char 


2 


OPS_waiver 


Char 


2 


WAR_waiver 


Char 


n 


SU8_waiver 


Char 


2 


NUC_waiver 


Char 


n 

L 


URL_waiver 


Char 


2 


MC_waiver 


Char 


n 

L 


RL_waiver 


Char 


2 


Date 


Date 


a 



Primary Key: Alpha+Code 
Indexes: Alpha, Code 



Remarks : 

Alpha number ot the midshipman to whom 
the disqualitier is assigned. 

Code ot the disqualifying condition 
assigned to the given midshipman. 

Flag which may modify the corresponding 
flag from the STANDARDS data base file 
for duty as a student naval aviator 
(i.e., AMstd). 

Permissible values include: 

W6 - not physically qualified/waiver 
granted 

LW - not physically qualif ied/1 iaited 
waiver granted 

WR - not physically qualified/ waiver 
requested 

UE - undergoing evaluation/status 
indeterminate at this time 
If none of the foregoing flags apply, 
the field is left blank. 

* SAA, except student naval flight officer. 
SAA, except special operations duty. 

SAA, except special warfare duty. 

SAA, except submarine duty. 

SAA, except surface nuclear duty, 

SAA, except unrestricted line. 

SAA, except U. 3. Marine Corps. 

SAA, except restricted line/staff corps. 

Date of most recent update to entry, 
MM/DD/YY format. 

* SAA - Same as above 



Figure 7. Description ot DISQUALIFIERS Data Base File 
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DISQUALIFIERS flag is blank, there is no modification, and 
the status flag would be NQ. The only exception to this 
scheme occurs when the DISQUALIFIERS flag is UE (undergoing 
evaluation). This means that regardless of what the 
STANDARDS flag specifies, the midshipman's status is 
indeterminate at that time, so the resulting status flag 
would be UE. Figure 3 shows the decision table for this 
process. 



If the STANDARDS flag for a 



warfare specialty is: 


PQ 


NQ 


NQ 


NQ 


NQ 


PQ or NQ 


And the corresponding DISQUALIFIERS 














flag is: 


UE 


WG 


LW 


WR 


• • 


UE 


Then the status flag for that 
warfare specialty is: 


PQ 


W6 


LW 


WR 


NQ 


UE 



Ke^: UE - not UE (i.e., WG, LW, WR, or blank) 
.. - blank 






+ 



Figure 8. Decision Table for STANDARDS — DISQUALIFIERS Flags 



The algorithm for determining a midshipman's overall 
physical qualification status is slightly different. 

First, the nine status flags for each disqualifying 
condition are determined as described in the preceding 
paragraph. These status flags are then compared within each 
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warfare specialty. If any single status flag is NQ, the 
midshipman is not physically qualified for that warfare 
specialty, and the summary flag evaluates to NQ. 

Similarly, if no status flags are NQ but at least one is 
UE, the midshipman's status is indeterminate, and the 
summary flag evaluates to UE. This process continues in 
like manner for the WR, LW, and WG flag values. A 
summary flag evaluates to PQ (physically qualified) if and 
only if all status flags for the particular warfare 
specialty are also PQ. Of course, if a midshipman has no 
disqualifying conditions, then all summary flags evaluate to 
PQ. Figure 9 illustrates this algorithm. 



IF (any status flag for a warfare specialty = NQ) 

THEN (summary flag = NQ) 

ELSE IF (any status flag for that warfare specialty = UE) 
THEN (summary flag = UE) 

END IF 

ELSE IF (any status flag for that warfare specialty = WR) 
THEN (summary flag = WR) 

ENDIF 

ELSE IF (any status flag for that warfare specialty = LW) 
THEN (summary flag = LW) 

ENDIF 

ELSE IF (any status flag for that warfare specialty = WG) 
THEN (summary flag = WG) 

ENDIF 

ELSE (summary flag = PQ) 

ENDIF 



Figure 9. Algorithm for Determining Summary Flags 
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Note that because the summary flags are dependent upon 
the STANDARDS and DISQUALIFIERS flags and therefore subject 
to relatively frequent change, they are not part of the 
permanent PQMS data base. Instead, the summary flags are 
reevaluated each time a detailed or summary report is 
generated and either immediately displayed to the CRT screen 
or printer or stored to a temporary data structure as 
described later. 

Finally, in addition to the Alpha, Code, and nine flag 
fields, each DISQUALIFIERS record has a date stamp which 
shows how current the data in the record is. As mentioned 
before, the key is Alpha+Code, and the file is indexed 
on both the Alpha and Code fields. 

E. COMMENTS DATA BASE FILE 

Although the BRIGADE, STANDARDS r and DISQUALIFIERS data 
base files provide a detailed profile of the physical 
qualification status of each midshipmen, they do not handle 
all contingencies. Therefore, PQMS also has a COMMENTS data 
base file which stores information which cannot be otherwise 
entered into the system. Figure 10 describes this file. 

The Alpha field establishes the tree relationship 
between BRIGADE and COMMENTS; each record in COMMENTS has 
one and only one parent record in BRIGADE. The Comment 
field may contain whatever information the user feels is 
needed to clarify the midshipman's physical qual i f i cati on 
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Data Base File: COMMENTS 



Description: Information impacting on physical qualification status which 

cannot otherwise be stored by POMS. 



Data Eleaents: 








Field Nafte 


Type 


Length 


Remarks : 


Alpha 


Char 


b 


Alpha number of the midshipman to whom 
the comment applies. 

EXAMPLE: 891234 


Comment 


Char 


60 


Comment entered as free text. 

EXAMPLE: ACL REPAIR SCHEDULED 27JUL36 


Date 


Date 


S 


Date comment was entered into data base 
MM/DD/YY format. 

EXAMPLE: 07/13/86 


Primary Key: Alpha (nonunique) 







! Index: Alpha+Date ! 

I • 

I < 

f- + 

Figure 10. Description o-F COMMENTS Data Base File 

status, and the date stamp shows when the comment was 
recorded. No unique key is explicitly defined for COMMENTS, 
but Alpha serves adequately as nonunique key. The file is 
indexed on the combined Alpha+Date fields. 

F. SUMMARY DATA BASE FILE 

The SUMMARY data base file, described in Figure 11, is 
actually a temporary structure. When a detailed physical 
qual if ication status report is generated (see Figure 1), 
SUMMARY provides a scratchpad for storing intermediate and 
final results of the summary flags algorithm of Figure 9. 



Data Base File: SUMMARY 



Description: Temporary data base File which stores personal data and summary 

flags for detailed or summary physical qualification reports 

Data Elements: 



Field Name 


Type 


Length 


Remarks: 


Alpha 


Char 


6 


Alpha number of the midshipman. 


Name 


Char 


25 


Last and first names of the midshipman, 
separated by a comma and truncated. 
EXAMPLE: MCGIFFIN, PHILO 


Company 


Char 


2 


Company to which midshi pman is assigned. 


flIR.flag 


Char 


2 


Summary flag which indicates midshipman’s 
physical qualification for duty as a 



a student naval aviator. 

Permissible values include: 

PQ - physically qualified 
NG - not physically qualified/waiver 
granted 

LW - not physically qualified/limited 
waiver granted 

WR - not physically qualified/waiver 
requested 

UE - undergoing evaluation/status 
indeterminate at this time 
NQ - not physically qualified 



NFO flag 


Char 


n 

im 


* SAA 


OPS J lag 


Char 


n 


SAA 


HAR.flag 


Char 


2 


SAA. 


SUB.flag 


Char 


2 


SAA 


NUC_f lag 


Char 


2 


SAA 


URL'flag 


Char 


n 

L 


SAA. 


MC_f lag 


Char 


2 


SAA, 


RL.flag 


Char 


? 


SAA 



except student naval flight officer, 
except special operations duty, 
except special warfare duty, 
except submarine duty, 
except surface nuclear duty, 
except unrestricted line, 
except U. S. Marine Corps, 
except restricted line/staff corps. 



Primary Key: Alpha 



* SAA - Same as above 



Index: Alpha or Company+Alpha (depending on report being generated) 



Figure 11. Description of SUMMARY Data Base File 



42 



When a summary reports are generated (see Figure 2) , SUMMARY 
stores personal data -from the BRIGADE file, as well as the 
results of the summary flag algorithm. In either case, the 
contents of SUMMARY are erased after the report is produced, 
leaving only a superstructure which can be reused for the 
next detailed or summary report. 

The Name field in the SUMMARY file is a combination of 
the midshipman's last and first names, truncated to 25 
characters to allow use of the built-in dBASE III report 
generator for summary reports. The other fields are 
self-explanatory. The key for SUMMARY is the Alpha field. 
When summary reports are generated, indexes are created “on 
the fly" based on either the Alpha or Company+Al pha fields, 
depending on the desired sort sequence. These indexes are 
also temporary and erased after the reports are printed. 
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VI. PRINCIPLES OF OPERATION 



Consistent with the data structure-ori ented design 
approach, the PQMS data base -files provide the basis Tor the 
procedural aspects o-f the system. In general , a hierarchy 
of modules exists as illustrated at a first level of detail 
by Figure 12. 



T ¥ 



: PQMS ! 

I 

I 

+ J. f + -I f + 

III I II 

■ I I - I I I 

+ + + + ^ + + + + + + + 

! Logon ! ! Update_ ! ! Update_ ! ! Update_ ! ! Generate_ ! ! Print_ ! 

! : ! BRIGADE ! ! STANDARDS ! ! DISQUALIFIER3 I i Reports’ ! ! STANDARDS ! 

■I K + + + f + + 1 ¥ + + 

I 

♦ 

*! + 

! Update^ ! 

! COMMENTS ! 



Figure 12. Hierarchy o-f PQMS Modules 



The system is menu-driven, so no knowledge o-f the underlying 
dBASE III language or programs is needed to effectively 
interact with PQMS. Visual and auditory prompts guide the 
user through all facets of the program, and extensive error- 
trapping validates inputs and maintains the integrity of the 
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data bases. The following sections overview the PQMS 
principles of operation. 

A. ENTERING AND EXITING PQMS 

To begin using PQMS, the user must first enter a 
password. (The user gets three attempts at this, after 
which processing is aborted and control returned to the 
microcomputer 's operating system.) After a successful 
logon, the user gets an opportunity to change the current 
password, an action strongly encouraged from time to time to 
prevent unauthorised access to the system. An introductory 
banner is displayed, followed by a Privacy Act Warning. 

PQMS then presents its main menu from which the user invokes 
the subordinate processing modules. When the user decides to 
exit PQMS, the Privacy Act Warning is again displayed before 
control reverts to the operating system. 

B. UPDATING PERSONAL DATA 

There are actually two phases to updating the personal 
data in the BRIGADE data base file. The first is an 
off-line process involving the Naval Academy Time— Sharing 
System (NATS) and the Brigade Roster File (BROSTER) . 

Running a NATS program called BR I GRE AD**-* , the user creates 
a file containing the alpha number. Social Security number, 
last name, first name, sex, date of birth, and company of 
every member of the Brigade. This file is then downloaded 
from the NATS Honeywell DPS 8 computer through a 2400— baud. 
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hard— wired line to the Branch Clinic microcomputer, using 
the KERMIT communication protocol on both computers to 
ensure reliable, error — checked data transfer. 

When this data is on the hard disk storage unit of the 
microcomputer, PQMS can update the BRIGADE data base as 
follows. After ensuring that the new file of personal data 
is in place, PQMS erases the old BRIGADE data base and its 
indexes, creates an empty data structure of the appropriate 
format, appends to that structure from the downloaded file, 
and reindexes the new BRIGADE data base. PQMS deletes then 
records in the DISQUALIFIERS and COMMENTS files which no 
longer have a counterpart in BRIGADE, and control reverts to 
the main menu. 

This process is unlike others in PQMS in that it takes 
place in batch mode and only periodically, rather than 
on-line and continuously as i s typical of the other updates. 
This raises a question as to whether the overall performance 
of PQMS suffers due to the BRIGADE data being outdated. 

This is not the case at all! Martin has identified five 
classes of data according to increasing complexity of 
update CRef. 7:pp. 281-284D: 

Class 0 - Unchanging data 

Class 1 - Data which are updated by simple replacement 
Class 2 - Data with independent nonrepeatabl e updates 
Class 3 - Data with time-critical updates 

Class 4 - Data for which an update may trigger an action 
in a different machine 
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The data element o-f BRIGADE most susceptible to change is 
Company, which is known to change at the end o-f the -fourth 
class (-freshman) year and on some other rare occasions. All 
other data elements are unchanging, except -for correction o-f 
erroneous initial entries. Therefore, the overall 
classification for BRIGADE is Class 1, in which case the 
replacement scheme used by PQMS is quite appropriate. 
Additional benefits are that the Branch Clinic does not have 
to replicate the substantial efforts of the Midshipman 
Personnel Office by initially entering or maintaining the 
data and that consistency between BROSTER and PQMS is 
assured. 

C. UPDATING STANDARDS DATA 

Updating the STANDARDS data base file involves three 
activities: adding, modifying, and deleting standards. When 
adding to the data base, the user first enters the code for 
the new standard. The entry is checked to ensure that it is 
five characters long and than the code has not already been 
used for any existing standard; the user is reprompted if 
the code fails either test. If the code is valid, a blank 
record is appended to STANDARDS, and the user enters a text 
description for the disqualifier and the standard flags for 
the nine warfare specialties (i.e., AIR_std, NFO_std, etc.). 
Each flag is validated as PO or NQ before proceeding to the 
next. Before storing and indexing the new record, PQMS 
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displays all input and asks for confirmation. Based on the 
user's response, the data is either committed to the data 
base along with the current date or cleared from memory. 

To modify a standard, the user first enters its five- 
digit code. If the code does not exist, an error message 
results. Otherwise, POMS displays the code, text 
description, and flags for the standard. After confirming 
that this is the desired record , the user enters a new 
series of flags, which are also validated as being PQ or NQ. 
As before, the user must confirm that the new data is to be 
committed to the data base, at which point the Date field of 
the record is changed as well. 

When attempting to delete a standard, PQMS first checks 
to see if the code which the user entered exists. If not, 
an error message results. If it does, the DISGUALIFIERS 
files is searched to see if any intersection records exist 
for that code- To maintain data base integrity, PQMS will 
not delete a standard which has any associated intersection 
records. Assuming this is not the case, the code, text 
description, and flags for the standard are displayed. The 
record is deleted only after approval by the user. 

Access to any of these three processes is through the 
Update_STANDARDS module. Once a subordinate module is 
entered, the add, modify, or delete cycle continues until a 
null (blank) is entered at the code prompt. Control then 
reverts back to the super ordi nate , Update_STANDARDS module. 
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D. UPDATING D I SQUAL I F I ERS DATA 



Updating the DISQUALIFIERS data base file is similar in 
several respects to updating STANDARDS. Options include 
adding, modifying, and deleting di squal i f i ers. Access to 
these is through the Update_DISQUALIFIERS menu, and after 
entering any of the subordinate modules, processing loops 
within that module until the user responds to the prompt for 
an alpha or Social Security number with a null value. On 
the other hand, updating DISQUALIFIERS requires some 
additional steps due to the inherent complexity of 
intersection records. 

Adding to the DISQUALIFIERS file begins by inputting 
either the alpha or Social Security number of the midshipman 
to whom the new disqualifier will be assigned. This 
flexibility is built into POMS because Naval Academy 
authorities typically identify midshipmen by alpha number, 
whereas the Branch Clinic uses Social Security number almost 
exclusively to identify Health Records, physical 
examinations, and the like. Assuming the length of the 
value provided is valid (i.e. , 6 or 9 characters) , PQMS 
chooses either the Alpha or SSN index and searches for the 
input value. If it is not found, an error message results, 
reprompting the user for a valid key. Otherwise, PQMS 
displays the midshipman's full name and company number and 
asks for confirmation that this is the desired individual. 
The user then enters the code of the disqualifier to be 
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assigned to that midshipman. A null value aborts the cycle, 
and an invalid entry causes reprompting. Another crucial 
check is made to ensure that an intersection record does not 
already exist -for that midshipman and di squal i -f i er code; if 
one does, an error message and reprompt are displayed. Next 
the code, text description, and standard flags for the 
di squal if ier are displayed, and the user enters any waiver 
flags for the nine warfare specialties (i.e., AIR_waiver, 
MFQ_wai ver , etc.). Each input is validated as being W6, LW, 
WR, UE or blank before continuing to the next waiver flag. 
ROMS then asks the user to approve entry of the new 
intersection record into the data base and either appends 
the current date or discards all input. 

The preliminary steps in modifying a DISQUALIFIERS 
record are similar to those above. A valid alpha or Social 
Security number yields the name and company number of the 
midshipman. A null code entry aborts the current 
modification process, while an error message and reprompt 
occur if an intersection record cannot be found for the 
given midshipman and disqualifier code. When the 
intersection record is found, the text description of the 
disqualifier, standard flags, and existing waiver flags are 
displayed. The user then inputs the new waiver flags, each 
of which is validated before continuing to the next. After 
confirmation, ROMS modifies the intersection record to 
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reflect the new set of waiver flags and current date; 
otherwise, the record left unchanged. 

Deleting a disqualifier is identical to modifying one 
through the point at which the text description, standard 
flags, and old waiver flags are displayed. POMS then either 
deletes or retains the intersection record , based on the 
user's confirmation input. 

E. GENERATING PHYSICAL QUALIFICATION STATUS REPORTS 

The Generate_Reports menu is the starting point for 
producing detailed or summary physical qualification status 
reports. The formats of these reports were presented 
in Figures 1 and 2. Five options are available: 

1. Detailed report on one individual (to CRT screen), 
including adding and deleting comments 

2. Detailed report on one individual (to printer) 

3. Detailed reports on all midshipmen in a given 
company and year group (to printer) 

4. Summary report on all midshipmen in a given company, 
sorted by year group (to printer) 

5. Summary report on all midshipmen in a given year 
group, sorted by company (to printer) 

These are the most demanding activities performed by PQMS, 

in terms of both input /output and processing, and 

consequently the most time-consuming. The sequence of the 

options roughly corresponds to the increasing complexity of 

the underlying processing tasks. 

A detailed report on an individual, either to the CRT 

screen or printer, requires only one user input — a valid 
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alpha or Social Security number. Using either of these, 

PQMS locates the midshipman record in the BRIGADE data base 
and displays the personal in-formation contained in that 
-file. Using the individual's alpha number, PQMS then 
searches the DISQUALIFIERS file for any related intersection 
records. If none are found, a statement to that effect is 
produced, and the summary flags for all warfare specialty 
default to PQ. Otherwise, PQMS uses the DISQUALIFIERS Code 
field to find the corresponding record in STANDARDS and 
compares the correspondi ng pairs of flags using the decision 
table of Figure S (i.e., AIR_std vs. AIR_waiver, NFO_std 
vs. NFO_waiver, etc.). The code, text description, date of 
the most recent change to the intersection record, and the 
nine status flags for that disqualifier are displayed, and 
the status flags are evaluated using the algorithm for 
summary flags of Figure 9. This process continues for all 
di squal i f i ers assigned to the midshipman. The nine summary 
flags are then displayed in their final form. 

At this point, the procedures for CRT display and 
printing diverge. In both cases, the alpha number is used 
to find all related records in the COMMENTS data base. When 
the detailed report is printed, these are directly output in 
order from the oldest to most recent. Because of the 80 x 
25 character limitation of a CRT screen, however, output 
pauses after the nine summary flags, and the user is 
prompted to press any key to clear the screen and display 
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any comments. This second screen also affords the user the 
opportunity to delete old comments or add new ones. No 
error — trapping is used per se. Instead, the comments screen 
is refreshed after each deletion or addition, after which 
the user may correct any errors. 

During the annual precommissioning physical examination 
evolution, midshipmen are usually processed in groups based 
on their company. To facilitate this, PQMS provides the 
ability to print detailed reports on all individuals in a 
particular company and year group. The user begins by 
entering the desired company number, then year group. A 
null value for either aborts the process. When valid inputs 
have been entered for both, the reports are printed as 
described previously for individual detailed reports, each 
on a separate page and in alphabetical order. 

To assist the Brigade Officers and Division of 
Professional Development in their career counseling roles 
and in administering the summer cruise and service selection 
programs, POMS can produce summary physical qualification 
status reports on all midshipmen in a particular company or 
year group. The processing logic for these reports is 
virtually identical. First, the user enters the desired 
company (or year group). As before, the input is validated, 
and a null entry aborts the process. Using the BRIGADE, 
DISQUALIFIERS, and STANDARDS data bases, PQMS determines the 
warfare specialty summary flags for each midshipman in the 



chosen subset. These are stored in the SUMMARY data 
structure, along with the midshipman's alpha number, name, 
and sex. These records are then indexed and printed. The 
company report lists each year group on a separate page, 
while the year group report lists each company on a separate 
page. A-fter either report is printed, the SUMMARY data 
structure is purged, leaving only its shell -for use by -for 
the next report, and the index is erased. 

F. PRINTING STANDARDS DATA 

The STANDARDS data base file can be printed in its 
existing form (see Figure 3) as a reference guide for 
updating the FQMS data base or to allow review by an outside 
authority. The procedure is strai ghtf orward. The user 
simply chooses whether the listing is to be sorted by code 
or alphabetically. PQMS then uses the appropriate index and 
produces a printout of all records in STANDARDS in the 
desired order. 
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VII. SUMMARY 



A. HARDWARE AND SOFTWARE CONFIGURATION 

Systems design consists o-f two phases, logical design 
and physical design. So -far, this thesis has only dealt 
with the logical design o-f the Physical Qual if ication 
Monitoring System, addressing design issues such as outputs, 
inputs, data base files, and procedures. There is nothing 
which precludes implementation of the PQMS logical design on 
MATS or any other Naval Academy computer system. 

Because of the development environment for the PQMS, 
however, the system was explicitly designed for 
implementation on a mi crocomputer . The hardware and 
software selected for the PQMS include: 

- Televideo XL Portable Computer (with RAM expansion to 
512 Kbytes) 

- Xebec 10HB External Hard Disk 

- Citizen MSP— 10 Dot Matrix Printer 

- Microsoft MS-DOS (Version 2.11) 

- dBASE III (Version 1.1) 

- KERMIT Communi cations System 

Actually, once the decision was made to use a mi crocomputer , 
there was little choice regarding the hardware and software. 
Based on a contract awarded to Federal Data Corporation in 
May 1985, the Televideo XL is now the standard personal 
mi crocomputer for the Navy and Air Force. Except for KERMIT 






which is public-domain software, the PQMS configuration is 
based exclusively on that contract. 

Federal procurement contracts are often a mixed 
blessing. This is particularly true of the PQMS. On the 
positive side, the problem of choosing from the growing 
number of mi crocomputers in today's market was eliminated, 
as were problems stemming from involving multiple vendors 
when building a system. The built-in serial port allows 
direct connection of the Televideo XL to the 2400— baud , 
hard-wired NATS communications lines, and the 10-megabyte 
external hard disk provides sufficient storage capacity for 
the PQMS files. 

Unf ortunatel y , the Televideo lacks a cassette tape or 
similar backup facility, so floppy disks are the primary 
backup medium for the PQMS. Since some of these files 
<s.g., DI3QUALIFIERS , COMMENTS) may exceed the 360-kilobyte 
capacity of a floppy disk, other alternatives are needed. 

As an interim measure, larger files can be backed up to 
NATS, but the long-term solution is a cassette tape backup 
unit. Another potential problem with the Televideo XL is 
speed. This microcomputer uses an Intel 8088 microprocessor 
chip and operates on a 4.77 MHz clock. While these are 
adequate for some app 1 i cat i ons , the PQMS detailed physical 
qualification status reports involve a large volume of 
input/output and a very heavy processing load, especially if 
the report is on an entire year group. The hard disk helps 
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somewhat by speeding up i nput /output , but the processor 
speed is the main problem. Potential solutions are to 
enhance the Televideo with an accelerator expansion card or 
to upgrade to a faster mi crocomputer (e.g. , IBM PC-AT, 
Compac DeskPro 286, etc.). 

B. POMS AS AN EXPERT SYSTEM 

Expert systems have received considerable attention in 
recent years and are at the heart of what is known as the 
"fifth generation" of computer technology. These systems 
are programs which have the knowledge and capability built 
in to allow them to operate at the expert's level. The two 
principle components of an expert system are a knowledge 
base and inference engine. The knowledge base contains 
both general facts of the problem domain and the heuristic 
or experiential knowledge of one or more experts from that 
field. The inference engine is the reasoning process which 
applies the domain and heuristic knowledge to the situation 
at hand to find an answer or solution. Many inference 
engines are generic in that they can be used with different 
knowledge bases to address problems from a variety of 
domains. CRef . 8:pp. 63-64, 76-791 

The PQMS is not designed as an expert system. Its 
reasoning processes are part of the program and cannot be 
segmented out for general use in other domains. However, 
the system closely mimics an expert system through its 
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ability to make physical qualification determinations using 
stored knowledge, to explain those determinations via its 
detailed reports, and to pass on knowledge -from one 
generation of user to the next. 

C. PQMS AS A PROTOTYPE 

Prototyping is a term long associated with the more 
mature engineering fields. For example, automobile and 
aircraft manufacturers have for years developed prototypes 
to test and refine new design concepts before going into 
full-scale production. Computer hardware engineers have 
also adopted this strategy. Based on a hardware 
requirements analysis, a preliminary configuration is 
designed using off-the-shelf and/or custom-built components. 
This prototype is then tested and modified until all 
requirements are met CRef. 4:p. 9D. More recently, software 
engineers have seen the applicability of such proven 
techniques from the older engineering disciplines to their 
own, and prototyping software is becoming increasingly more 
common . 

There are a number of reasons for prototyping software 
systems. Sometimes prototypes are warranted because of the 
high cost or high risk inherent in a given project; consider 
the relevance of software prototyping to the Strategic 
Defense Initiative. Certain types of systems <e.g., 
decision support systems) are best developed using 
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prototyping because of their lack o-f structure and 
non-repeti ti ve nature. CRef. 3:p. 63 

PQMS does not -fall into either o-f those categories, but 
there are still compelling reasons -for using this approach. 
Although the role o-f the Branch Clinic in monitoring 
physical qualifications is wel 1 -understood , those 
information needs are not easily translated into a formal 
requirements specification. Even if they were, prototyping 
is still appropriate in instances where the analysts have no 
prior experience in building such a system [Ref. 9:p. 2283. 
This is certainly the case with PQMS. Therefore, the system 
has been designed as a prototype to clarify the information 
requirements of the Branch Clinic and .to allow for the lack 
of experience of the anal yst /programmer . 

D. EXTENSIONS OF PQMS CONCEPTS 

The PQMS prototypes a highly specialized, si te— speci f i c 
application. However, there are at least two possible 
extensions of this system. 

The logical design of the system should be adaptable for 
use by the other service academies. West Point and the Air 
Force Academy also commission their graduates into a variety 
of warfare specialties, each with its own physical 
qualification standards. The Coast Guard Academy sends all 
graduates to sea duty, but still must determine whether they 
are physically qualified for a regular Coast Guard 
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commission. Those who are not must accept commissions in 
Coast Guard Reserve. 

Second, the idea of establishing a knowledge base of 
physical qualification standards has merit. This knowledge 
base could be distributed to naval medical treatment 
facilities, along with programs to compare an individual's 
physical examination results with those standards. This 
could provide invaluable assistance in those settings where 
the health care provider is not familiar with current 
physical standards or with the wai verabi 1 i ty of certain 
disqualifying conditions. In addition, by building the 
knowledge base separate from the underlying programs, 
updates could be easily compiled and issued to field 
activities, ensuring uniform use of current information 
throughout the Navy. 
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